home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 179 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.4 KB
  1. Path: solon.com!not-for-mail
  2. From: Dan Pop <danpop@mail.cern.ch>
  3. Newsgroups: comp.lang.c.moderated,comp.std.c
  4. Subject: Re: Function returning structure
  5. Date: 24 Jan 1996 11:08:33 -0600
  6. Organization: CERN European Lab for Particle Physics
  7. Sender: clc@solutions.solon.com
  8. Approved: clc@solutions.solon.com
  9. Message-ID: <4e5p2h$6hk@solutions.solon.com>
  10. References: <4e2ki8$l0k@solutions.solon.com>
  11. NNTP-Posting-Host: solutions.solon.com
  12. X-NNTP-Posting-Host: hpl3sn03.cern.ch
  13. X-Newsreader: NN version 6.5.0 #7 (NOV)
  14. X-Mail2News-Path: disperse.demon.co.uk!post.demon.co.uk!dxmint.cern.ch!hpl3sn03.cern.ch
  15.  
  16. bnelson@netcom.com (Bob Nelson) writes:
  17.  
  18. >/*
  19. >Consider the following code -- in which a structure member is of type
  20. >array of char and an instance of that structure is returned from a
  21. >a function.
  22. >
  23. >The Standard [6.3.2.3] says that the dot operator designates a member
  24. >of a structure. (It goes on to add -- in its example text -- that f().x
  25. >is a valid postfix expression though not an lvalue, presuming that
  26.                                ^^^^^^^^^^^^^^^^^^^^
  27. This is the clue you were looking for!
  28.  
  29. >f is a function returning a structure and that x is member).
  30.  
  31. >With that in mind -- does the standard have anything that might
  32. >disqualify member selection (in a non-assignment context) if that
  33. >member is of type array and that structure is returned by a function?
  34. >One current, popular compiler fails to compile this code -- diagnosing
  35. >an "invalid use of non-lvalue array". 
  36.  
  37. gcc was right, IMHO.
  38.  
  39. >*/
  40. >
  41. >#include <stdio.h>
  42. >
  43. >struct T {
  44. >    char c[81];
  45. >};
  46. >
  47. >struct T func(void)
  48. >{
  49. >    static struct T s = { "returned from func" };
  50. >
  51. >    return s;
  52. >}
  53. >
  54. >int main(void)
  55. >{
  56. >
  57. >    printf("%s\n", func().c);    
  58. >    return 0;
  59. >}
  60.  
  61. The compiler has to take the address of func().c and pass it to printf.  
  62. But func().c is not an lvalue, hence its address cannot be taken.  
  63. I'm not sure this is the only possible interpretation, so I'm crossposting
  64. this article to comp.std.c.
  65.  
  66. The OSF/1 and Solaris compilers complain too, but the most "interesting"
  67. behaviour is displayed by the IRIX compiler:
  68.  
  69.     sgiref:~/tmp 7> uname -a
  70.     IRIX sgiref 5.2 02282016 IP22 mips
  71.     sgiref:~/tmp 8> cc test.c
  72.     sgiref:~/tmp 9> cc -ansi test.c
  73.     Assertion failed: !IS_STRICT_ANSI, file expr_cg.c, line 2285
  74.     cfe: Fatal: test.c: IOT instruction
  75.  
  76. Dan
  77. -- 
  78. Dan Pop
  79. CERN, CN Division
  80. Email: danpop@mail.cern.ch 
  81. Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
  82.